AWS再入門ブログリレー2022 Amazon FSx for Windows File Server編

AWS再入門ブログリレー2022 Amazon FSx for Windows File Server編

弊社コンサルティング部による『AWS 再入門ブログリレー 2022』の24日目のエントリで、テーマは「Amazon FSx for Windows File Server」です。「Windows向けのファイルサーバーサービス」ということは知っていても「他のストレージサービスとの違いは?」「導入するためには何が必要?」といった点はあまり知らないという方もいらっしゃるのではないでしょうか。そんな方はこの機会に「再入門」してみませんか?
Clock Icon2022.03.08

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

みなさん、こんにちは!
福岡オフィスの青柳です。

当エントリは弊社コンサルティング部による『AWS 再入門ブログリレー 2022』の24日目のエントリです。

このブログリレーの企画は、普段AWSサービスについて最新のネタ・深い/細かいテーマを主に書き連ねてきたメンバーの手によって、今一度初心に返って、基本的な部分を見つめ直してみよう、解説してみようというコンセプトが含まれています。

AWSをこれから学ぼう!という方にとっては文字通りの入門記事として、またすでにAWSを活用されている方にとってもAWSサービスの再発見や2022年のサービスアップデートのキャッチアップの場となればと考えておりますので、ぜひ最後までお付合い頂ければ幸いです。

では、さっそくいってみましょう。24日目のテーマは「Amazon FSx for Windows File Server」です。

FSx for Windows File Serverとは

「Amazon FSx for Windows File Server」とは、AWSのストレージサービスの一つであり、ストレージサービスの中の「ファイルストレージ」に分類されるサービスです。

FSx for Windows File Serverの特徴は、一言で表すと「Windowsとの親和性が極めて高い」に尽きます。

FSx for Windows File Serverは、Sambaなどを使った「ある程度Windowsと互換性のあるストレージサービス」ではなく、内部で実際にWindows Serverが動作している「Windowsとネイティブな互換性を持つストレージサービス」なのです。

Windowsネイティブ互換

「Windowsとネイティブな互換性を持つ」というのは、以下のような要素を意味します。

  • ファイルシステムに「NTFS」を採用
  • ファイル共有プロトコルに「SMB」を採用
  • 認証や認可の基盤としてActive Directoryを使用

SambaなどSMB互換のプロトコルを採用したファイルサーバーでは、ファイル共有プロトコルはSMBと互換性があってもファイルシステムはLinuxの「ext」を採用していることがあり、NTFS特有の「拡張属性」に対応していないなど完全な互換性が得られない場合があります。

その結果、既存のWindowsサーバーやWindowsクライアントがファイルサーバーを利用する際に、アプリケーションが互換性の問題で動作しなかったり、エクスプローラーで操作できる内容に違いが生じたりすることに繋がります。

Windowsのファイルサーバー関連機能を利用できる

FSx for Windows File Serverは内部で実際にWindows Serverが動作しているため、Windows Serverが提供するファイルサーバー関連の様々な機能が利用できます。

  • ボリュームシャドウコピーサービス
  • ストレージクォータ
  • データ重複排除、など

SambaなどSMB互換のプロトコルを採用したファイルサーバーでは、これらの機能が利用できなかったり、同等の機能が提供されていてもWindowsとは設定方法や使用感が異なる場合があります。

このようなWindos Serverが提供する機能に魅力を感じる場合や、既存システムで既にこれらの機能を利用している場合には、移行先としてFSx for Windows File Serverを選択するメリットとなります。

他のストレージサービスとの使い分け

ブロックストレージ/オブジェクトストレージ/ファイルストレージ

AWSで利用できるストレージサービスは、大きく以下のカテゴリに分かれています。

  • ブロックストレージ
  • オブジェクトストレージ
  • ファイルストレージ

「ブロックストレージ」のカテゴリに分類されるサービスには「EBS (Elastic Block Store)」があります。

EBSは、EC2にアタッチした上で、EC2上で稼働するOSからマウント・フォーマットを行うことで、初めて利用することができます。(実際にはマウントやフォーマットは自動的に行われることもあるため、意識せずに利用している場合もあります)
EC2とEBSは1対1で対応付けられるため、複数のEC2から1つのEBSを共有して利用することはできません。
また、オンプレミスやインターネットのサーバー・クライアントからEBSに対して直接アクセスするような利用の仕方もできません。

ブロックストレージ (EBS) は、以下のような場面で選択するとよいでしょう。

  • EC2が処理を行う上で、ある程度の容量のストレージが必要
  • アプリケーションの互換の都合上、OS上で「ローカルストレージ」として認識される必要がある
  • 複数のEC2間でストレージを共有する必要がない (共有する場合は別途共有のためのストレージサービスを利用)

「オブジェクトストレージ」のカテゴリに分類されるサービスには「S3 (Simple Storage Service)」があります。
また、アーカイブ用途に特化したサービスとして「S3 Glacier」があります。

S3は、元々はインターネット経由で利用できるオンラインストレージサービスとして提供を開始しました。
現在では、インターネット経由での利用に加えて、AWSのEC2やその他のサービスから利用したり、オンプレミス環境からDirect ConnectやVPNを介して利用することも可能になっています。

S3へアクセスする際にはHTTPSベースの「REST API」、または、REST APIをベースにした各種SDKやCLIコマンドを使用します。
ドラッグ&ドロップなどの操作で利用できるようにしたGUIツールもサードパーティから提供されていますが、内部的にはREST APIの呼び出しとなっており、後述する「ファイルストレージ」とは根本的に異なる仕組みのストレージサービスとなっています。

オブジェクトストレージ (S3) は、以下のような場面で選択するとよいでしょう。

  • アプリケーションが利用するデータを安価に保管したい
  • AWS上で新規に作成するアプリケーション (特にサーバーレスアーキテクチャ) からの利用
  • 既存アプリケーションをAWSへ移行する際、ファイルアクセス処理の対象を既存ストレージからS3へ変更できる

「ファイルストレージ」のカテゴリに分類されるサービスには「EFS (Elastic File System)」および「FSx」シリーズの各種サービスがあります。

AWSのファイルストレージサービスは、Linux/Unixで使われている「NFS」や、Windowsで使われている「SMB」など、既存のOSや製品で使われているファイル共有プロトコルをベースに提供されています。
ファイルストレージサービスは、ベースとなるプロトコル毎にサービスが用意されており、目的に合わせてサービスを選ぶことになります。

S3は汎用的なストレージサービスとして高い信頼性や拡張性を持つ優れたサービスですが、オンプレミスで使われているファイルサーバーから移行するためには、プロトコルの違いやストレージ特性の違い (レイテンシーやスループットなど) のためにアプリケーションの大幅な改修が必要になったり、性能や機能の要件を満たせない場合があります。
これに対して、ファイルストレージの各サービスは、既存のプロトコルをベースにしており、また、ストレージ特性も利用目的に応じたものとなっているため、オンプレミスのファイルサーバーからの移行がし易いものとなっています。

ファイルストレージサービスは、原則としてVPCから利用する前提となっています。
Direct ConnectやVPNでオンプレミスとAWSを接続した環境では、オンプレミスのサーバーやクライアントから利用することも可能です。
一方で、インターネットからアクセスする利用方法には向いていないサービスです。

ファイルストレージは以下のような場面で選択するとよいでしょう。

  • 複数のEC2でデータを共有したい
  • ECSやEKSで稼働する大量のコンテナ間でデータを共有したい
  • オンプレミスで利用しているNFSやSMBに準拠したファイルサーバーから移行したい
  • 既存アプリケーションをAWSへ移行する際、ファイルアクセス処理を改修したくない・改修できない

ファイルストレージサービスの選択

「ファイルストレージ」に分類されるサービスには、以下のものがあります。(EFS + FSxシリーズの4つのサービス)

サービス 特徴
EFS (Elastic File System) Linux/Unixで使われるNFSプロトコルと互換性を持つファイルサーバー
FSx for Windows File Server Windowsとネイティブな互換性を持つファイルサーバー
FSx for Lustre HPCや機械学習などの用途に最適な高性能ファイルサーバー
FSx for NetApp ONTAP エンタープライズ向けネットワークストレージベンダー「NetApp」が提供する「ONTAP」システムと互換性を持つファイルサーバー
FSx for OpenZFS Linuxの高機能なファイスシステム「OpenZFS」と互換性を持つファイルサーバー

これらのサービスは、大きく以下のように分類できます。

  • 標準的な用途に向けたサービス
    • EFS
    • FSx for Windows File Server
  • 特定用途に向けたサービス
    • FSx for Lustre
  • 高機能・高性能なファイルストレージを提供するサービス
    • FSx for NetApp ONTAP
    • FSx for OpenZFS

「EFS」「FSx for Windows File Server」は、それぞれ、Linux/Unixで使われている「NFSプロトコル」、および、Windowsで使われている「SMBプロトコル」との互換性を持つファイルサーバーを提供するサービスです。
基本的には、利用するサーバーやクライアントがLinux/Unix系であるか、Windows系であるか、によってサービスを選択します。
Linux/UnixとWindowsが混在しており、かつ、両者間でデータを共有する必要がある環境では、どちらかの環境に合わせて「EFS」か「FSx for Windows File Server」のいずれかを選択することになります。
Linux/Unix向けの「SMBクライアント」、または、Windows向けの「NFSクライアント」が、OS標準機能もしくはサードパーティツールとして用意されているため、それらの利用も合わせて検討します。
EFS (NFSプロトコル) とFSx for Windows File Server (SMBプロトコル) のいずれを選択するのかは、「どちらを利用するサーバー/クライアントが多いか」「互換性がクリティカルな問題となるのはどちらか」といった観点で選択することになるかと思います。

「FSx for Lustre」は、大規模のクラスターコンピューティングやスーパーコンピューターで利用されている分散ファイルシステムである「Lustre」をベースにしたサービスです。
AWSにおいても、HPC (ハイパフォーマンスコンピューティング) や機械学習など多数のクラスターノードで分散処理を行うシステムからの利用が想定されています。
このような用途のため、ストレージの性能 (レイテンシー、スループット、IOPSなど) が非常に高いという特徴があります。

「FSx for NetApp ONTAP」は、エンタープライズ向けNAS市場で高いシェアを持つ「NetApp」社の製品で採用されているNAS専用OS「ONTAP」をベースにしたサービスです。
FSx for NetApp ONTAPの特徴として、NFSおよびSMBの両方のプロトコルに対応している点が挙げられます。 また、iSCSIによる接続にも対応しています。
FSx for NetApp ONTAPは、オンプレミスのONTAP製品と同様の高機能なファイルサーバー関連機能を利用することができます。(例「重複排除」「データ圧縮」「スナップショットを利用したバックアップやレプリケーション」など)
NetApp管理ツールを用いることで、オンプレミスのONTAP製品と同様にこれらの機能を管理することが可能です。

「FSx for OpenZFS」は、Solaris用ファイルシステム「ZFS」のオープンソース版である「OpenZFS」をベースにしたサービスです。
Unix系のファイルシステムの中では比較的新しい規格であり、既存のUnix系ファイルシステムに対して性能面・機能面で優位な点を多く持っています。

「FSx for NetApp ONTAP」や「FSx for OpenZFS」は、NFSプロトコルやSMBプロトコルが利用できるという点で「EFS」や「FSx for Windows File Server」との比較対象になる場合があります。
選定のポイントとしては以下の点が挙げられると思います。

  • 「FSx for NetApp ONTAP」や「FSx for OpenZFS」が持つ高い性能や機能が求められているかどうか
  • ONTAPやOpenZFSの設定や運用管理のノウハウがあるかどうか
  • 利用料金の面で折り合いが付くかどうか

これらの条件がクリアされるのであれば「FSx for NetApp ONTAP」や「FSx for OpenZFS」を選択してよいのではないかと思います。
そうでなければ、「EFS」や「FSx for Windows File Server」を選択して問題ないのではないかと思います。

クライアントの要件

FSx for Windos File Serverの利用をサポートしているOSは以下の通りです。
(「クライアント」と表現しましたが、ここでは「ファイルサーバーへアクセスするクライアント」という意味で、WindowsサーバーOSも含みます)

  • Windows
    • WindowsサーバーOS: Windows Server 2008以降のバージョン
    • WindowsクライアントOS: Windows 7以降のバージョン
  • Linux
    • 最新のLinuxバージョン (cifs-utilsツールを使用)

クライアントは、EC2インスタンス (上記OSに該当するもの) やオンプレミス環境のサーバー・クライアントの他、AWSの以下のサービスもクライアントとしてサポートされています。

  • ECS
  • VMware Cloud on AWS
  • WorkSpaces
  • AppStream 2.0

サポートされる「SMBプロトコル」のバージョンについて

FSx for Windos File Serverがサポートしている「SMBプロトコル」のバージョンは「2.0以降」となっています。
SMB 2.0は「Windows Vista」および「Windows Server 2008」で採用されたバージョンであり、以後、以下のようにバージョンアップされています。

  • SMB 2.0: Windows Vista、Windows Server 2008で採用
  • SMB 2.1: Windows 7、Windows Server 2008 R2で採用
  • SMB 3.0: Windows 8、Windows Server 2012で採用
  • SMB 3.0.2: Windows 8.1、Windows Server 2012 R2で採用
  • SMB 3.1.1: Windows 10、Windows Server 2016で採用 (Windows 11、Windows Server 2019/2022でも引き続き採用)

上記に挙げたSMBプロトコルバージョンおよびOSであれば、FSx for Windos File Serverの利用がサポートされているということになります。

「SMB 2.0」よりも前のバージョン、具体的には「SMB 1.0」あるいは「CIFS」については、FSx for Windos File Serverではサポートされていません。
SMB 1.0/CIFSは古い暗号化技術が使われていることから現在では「脆弱性のあるプロトコル」とされており、マイクロソフトおよび各所で「使用しないことが推奨」されています。

※ SMBプロトコルのバージョンや歴史に関しては、Wikipediaの下記ページを参考にしました。
Server Message Block - Wikipedia

導入構成

FSx for Windows File Serverを導入する際、「構成」に関して特に考慮すべき点として以下のものがあります。

  • 連係するActive Directoryの種類の選択
  • シングル構成/冗長構成の選択
  • 「管理サーバー」の設置

連係するActive Directoryの種類の選択

FSx for Windows File Serverを導入・利用する際、Active Directory (AD) との連係が必須となっています。
連係するADの種類については、以下の2つのパターンから選択が可能です。

  • (1) 「AWS Directory Service」の「Managed Microsoft AD」を使用する
  • (2) 「自己管理型AD」を使用する

(1)(2) いずれの場合も、Active DirectoryドメインへFSx for Windows File Serverを参加させて利用することになります。(AWSドキュメントでは「ドメインへの接続」や「ドメインへの結合」という表記がされている箇所もありますが、要はドメイン参加です)

Active DirectoryドメインへFSx for Windows File Serverを参加させ、同じドメインに参加しているWindowsサーバーやクライアントが、ドメインによる認証・認可 (アクセス許可) を得ることにより、FSx for Windows File Serverの共有フォルダーへアクセスすることができる仕組みです。

(1) の場合、Directory Serviceに含まれるサービスのうち「Managed Microsoft AD」のみが対応しています。 「Simple AD」や「AD Connect」との連係はできないため、注意してください。

FSxと同じVPC内にあるManaged Microsoft ADとの連係はもちろん、「異なるVPCにあるManaged Microosft AD」「別アカウントにあるManaged Microsoft AD」との連係も可能です。
その場合、以下の前提条件を満たしている必要があります。

  • 異なるVPC: VPC間がVPCピアリングまたはTransit Gatewayで接続されていること
  • 別アカウント: 対象のManaged Microsoft ADで「ディレクトリの共有」が設定されていること

同じVPC、異なるVPC、別アカウント、いずれの場合であっても、FSx for Windows File ServerとManaged Microsoft ADとの間で特定ポートの通信が可能である必要があります。
詳細はAWSドキュメントの当該ページを確認してください。
AWS Directory Service for Microsoft Active Directory での Amazon FSx の使用する - Amazon FSx for Windows File Server

(2) の「自己管理型AD」とは、以下のようなものを指します。

  • オンプレミス環境に設置されているActive Directoryドメインコントローラー
  • EC2 Windowsインスタンス上に構築されたActive Directoryドメインコントローラー

いずれの場合も、FSx for Windows File ServerとActive Directoryドメインコントローラーとの間で特定ポートの通信が可能である必要があります。
詳細はAWSドキュメントの当該ページを確認してください。
セルフマネージド Microsoft AD を使用するための前提条件 - Amazon FSx for Windows File Server

加えて、自己管理型ADの場合、FSx for Windows ServerをActive Directoryドメイン上で管理するために必要な各種設定を、ドメインコントローラー上で実施する必要があります。(詳細は後述)
特に「FSx for Windows Serverの導入部署」と「Active Directoryの管理部署」が異なる場合 (例えば、前者が部門内インフラ管理部署、後者が全社情シス部門) に問題となる場合がありますので、事前に確認・調整を行っておくことをお勧めします。

シングル構成/冗長構成の選択

FSx for Windows File Serverは、信頼性/可用性の要件に応じて「シングル構成」「冗長構成」のいずれかを選択することができます。
選択可能な構成は以下の通りです。

  • シングル構成
    • シングルAZ 1
    • シングルAZ 2
  • 冗長構成
    • マルチAZ

シングル構成である「シングルAZ (1/2)」は、1台のWindowsファイルサーバーを1つのAZ上に配置する構成です。
1台のみであるため、AZ障害、あるいは、ファイルサーバーが稼働するために必要なリソース (コンピューティング、ディスク、ネットワークなど) のコンポーネント障害が発生した場合、サービスが利用不可となります。

冗長構成である「マルチAZ」は、2台のWindowsファイルサーバーを2つのAZ上に分散配置する構成です。
2台のファイルサーバーはWindowsの「DFSレプリケーション」(分散ファイルシステムレプリケーション) 機能により常時同期が行われ、AZ障害やコンポーネント障害が発生した場合、障害の影響を受けなかったファイルサーバーによってサービスが継続されます。

シングルAZには「シングルAZ 1」「シングルAZ 2」の2つの種類があります。
これは歴史的経緯によるもので、FSx for Windows File Serverのサービス開始当初は「シングルAZ 1」相当の構成のみが提供されていました。(マルチAZも提供されていなかった)
その後「マルチAZ」が提供されましたが、その際に「シングルAZ 2」も提供されるようになりました。
マルチAZの提供に合わせてFSx for Windows File Serverの内部構成に変更があり、この変更がシングルAZにも適用されたものが「シングルAZ 2」となっています。
そのため、シングルAZ 1とシングルAZ 2とでは利用可能な機能に差異があります。(詳細は下記のブログ記事で解説されています)

「シングルAZ 1」では利用できていたが「シングルAZ 2」で利用できなくなった機能は、「DFSレプリケーション」のみです。(マルチAZの実装にDFSレプリケーションが使われているため、利用者へDFSレプリケーション機能の利用を開放しなくなったものだと思われます)
一方、「シングルAZ 1」では利用できなかったが「シングルAZ 2」になって利用できるようになった機能には、「ストレージタイプとしてHDDを選択」「SMBのCA共有 (※SQL Serverのストレージとして利用する際に必要)」があります。

AWSは最新の構成である「シングルAZ 2」を推奨しているため、特に理由が無い限りは「シングルAZ 2」の方を選択するようにしましょう。

「管理サーバー」の設置

FSx for Windows File Serverを導入後に運用していく上で、「管理サーバー」の設置を強くお勧めします。

FSx for Windows File Serverの導入はAWSマネジメントコンソールを使って行うことができますが、導入後に「Windowsファイルサーバー」としてFSx for File Serverを設定・運用していく際に、マネジメントコンソールから行えない項目が多々あります。
Windowsファイルサーバーとしての設定・運用を行うには、FSx for Windows File Serverに対してWindowsの管理機能を使う必要があります。

冒頭で説明した通り、FSx for Windows File Serverは内部で実際のWindows Serverが動作していますが、AWSのマネージドサービスであることから「リモートデスクトップ接続 (RDP)」による直接の接続・ログオンは行えなくなっています。
同様の理由で、SSMセッションマネージャーによるターミナルセッション (コマンドコンソール接続) も利用できません。

ではどのようにして設定・運用を行うのかと言いますと、管理用のWindowsマシンを別途用意して、Windowsの「システム管理ツール」および「PowerShell」を使ってFSx for Windows File Serverに対してリモート接続を行った上で、設定・運用を行うということになります。

この「管理用のWindowsマシン」は以下の条件である必要があります。

  • FSx for Windows File Serverと同じActive Directoryドメインに参加している
  • FSx for Windows File Serverに対する管理者権限を持つActive Directoryドメインユーザーでログオンしている

これはオンプレミス環境のWindowsサーバーやWindowsクライアントでも条件さえ満たせば利用可能なのですが、FSx for Windows File Serverと同じVPC上にEC2 Windowsインスタンスを作成して「FSx管理サーバー」として利用することをお勧めします。

何故かと言いますと、ネットワーク的なトラブル (特にDirect ConnectやVPNの障害) でオンプレミスからFSx for Windows File Serverへの接続が行えなくなった場合であっても、最も近い場所に管理サーバーを配置しておくことでFSx for Windows File Serverの状況確認や設定変更が行えるためです。 (利用しない時にはEC2インスタンスを停止しておけば、コストも最低限に抑えることができます)

なお、管理サーバーは他の機能と兼用することも可能です。
例えば、Managed Microsoft ADを使用する場合に別途「AD管理用サーバー」を設置するパターンが多いと思いますが、各機能の管理者ユーザーの権限を適切に管理することを前提に、これらの管理機能を同一EC2インスタンスに同居させることは問題ありません。
(ただし、業務サーバーと管理サーバーを兼用するようなことは避けましょう)

構築方法

FSx for Windows File Serverを構築する時の「流れ」は、以下のようになります。

  • 事前準備
    • Active Directoryの準備を行う
      • AWS Managed Microsoft ADの場合
      • 自己管理型ADの場合
    • 管理サーバーの準備を行う
    • セキュリティグループを用意する
    • 「Active Directory検証ツール」を実行する (自己管理型ADの場合のみ)
  • リソース作成
    • FSx for Windows File Serverの「ファイルシステム」を作成する
  • リソース作成後の設定
    • 共有フォルダーを作成する
    • NTFSアクセス権を設定する
  • 各種オプション機能の設定
    • データ重複排除
    • ボリュームシャドウコピー
    • など

事前準備

Active Directoryの準備を行う

まず、FSx for Windows File Serverが連係するActive Directoryの準備を行います。

連係するADとして「AWS Managed Microsoft AD」を選択する場合は、特に対応が必要となる点はありません。
前章で説明した「FSx for Windows File ServerとManaged Microsoft ADとの間の通信要件」を満たす必要がありますので、この後の「セキュリティグループを用意する」の手順で適切な設定を行ってください。

連係するADとして「自己管理型AD」を選択する場合は、事前に以下の作業を行う必要があります。

  • FSx for Windows File Serverを格納する「OU」を作成して、「権限の委任」の設定を行う
  • FSx for Windows File Serverが稼働するための「サービスアカウント」と呼ばれるドメインユーザーを作成する
  • FSx for Windows File Serverを管理するための「管理者グループ」と「管理者ユーザー」を作成する

これらの作業の詳しい説明と手順については、下記のブログ記事を参照してください。

加えて、Managed Microsoft ADを選択した場合と同様に、ADとFSx for Windows File Serverとの間の通信要件を満たすようにセキュリティグループの設定を行う必要があります。

管理サーバーの準備を行う

前章で説明した通り、FSx for Windos File Serverの設定・運用を行うための「管理サーバー」を設置することをお勧めします。

FSx for Windows File Serverと同じVPC上にEC2 Windowsインスタンスを作成して、FSx for Windows File Serverと同じActive Directoryドメインへの参加を行います。

FSx for Windows File Serverを導入した後は、この「管理サーバー」へ「FSx管理者ユーザー」でログオンして、各種管理を行っていくことになります。

セキュリティグループを用意する

FSx for Windows File Serverへ適用する「セキュリティグループ」を作成します。
設定が必要な通信要件には以下のものがあります。

  • FSx for Windows File ServerとADとの間の通信要件を満たすポート許可設定 (インバウンド・アウトバウンド)
  • クライアントがFSx for Windows File Serverへアクセスするためのポート許可設定 (インバウンド)
  • 管理サーバーからFSx for Windows File Serverへアクセスするためのポート許可設定 (インバウンド)

また、Managed Microsoft ADを利用している場合や、自己管理型ADをEC2インスタンス上に構築している場合は、これらのADに対してセキュリティグループを適切に設定しておきます。

「Active Directory検証ツール」を実行する (自己管理型ADの場合のみ)

自己管理型ADを使用する場合、「FSx for Windows File ServerとADとの間の通信要件を満たしているか」「AD上で事前に作成するOUやドメインユーザーが要件通りになっているか」という点が、FSx for Windows File Serverが問題なく導入できるかどうかに大きく影響します。

これらの要件が正しく満たされているかどうかをチェックするために、AWSがFSx for Windows File Server向けに提供している「Active Directory検証ツール」を利用できます。
検証ツールを使ってチェックを行うことは必須ではありませんが、FSx for Windows File Serverの導入段階あるいは導入後にトラブルが発生することを避けるために、検証ツールの利用をお勧めします。

「Active Directory検証ツール」の詳しい説明と使用方法については、下記のブログ記事を参照してください。

リソース作成

FSx for Windows File Serverの「ファイルシステム」を作成する

事前準備が整いましたら、FSx for Windows File Serverの構築を行います。

FSx for Windows File Serverに関する唯一のAWSリソースは「ファイルシステム」と呼ばれます。
「ファイルシステム」≒「ファイルサーバー」と捉えても問題ないでしょう。

ファイルシステムを作成するには、以下のような手段が用意されています。

  • マネジメントコンソール
  • AWS CLI
  • 各種IaC (CloudFormation、Terraformなど)

ファイルシステム作成の際、以下の要素をパラメーターとして指定します。

  • ファイルサーバーの基本的な諸元
    • デプロイタイプの選択 (「シングルAZ (1/2)」「マルチAZ」)
    • ストレージタイプの選択 (「SSD」「HDD」)
    • ストレージ容量の指定
    • スループット容量の指定
  • ネットワーク設定
    • 配置先VPC
    • 配置先サブネット (シングルAZ時は1つ、マルチAZ時は2つ)
    • 適用するセキュリティグループ
  • Active Directoryの情報
    • 連係するActive Directoryの種類の選択 (「Managed Microsoft AD」「自己管理型AD」)
    • 選択したADの種類に応じて、ADへ接続するための諸情報を入力します
      • Managed Microsoft ADの場合: ディレクトリID
      • 自己管理型AD: ドメイン名、DNSサーバーIPアドレス、サービスアカウントや管理者ユーザーの認証情報、など

その他の設定項目として、以下の機能に関する設定も指定することが可能です。

  • データ保存時の暗号化 (KMSキー種類の選択)
  • 監査ログ
  • DNSエイリアス
  • バックアップ

上記以外の機能 (例えば「データ重複排除」など) に関しては、ファイルシステムの作成後に設定を行います。

リソース作成後の設定

「ファイルシステム」リソースを作成した後は、まず、ファイルサーバーとして利用するための最低限の設定として「共有フォルダーの作成」と「アクセス権限の設定」を行います。

共有フォルダーを作成する

ファイルシステムを作成した直後は、デフォルトで「share」という名前の共有フォルダーが作成済みです。
これをそのまま運用で使ってもよいのですが、「名前を指定して共有フォルダーを作成したい」「2つ以上の共有フォルダーを作成したい」という場合には、追加で共有フォルダーの作成を行う必要があります。

共有フォルダーの作成は、「管理サーバー」上でWindowsシステム管理ツール「共有フォルダー」(fsmgmt.msc) を使ってFSx for Windows File Serverへリモート接続した上で、「共有フォルダー」管理ツールを操作して行います。

共有フォルダーの作成および管理の方法については、下記のAWSドキュメントページを参照してください。

ファイル共有 - Amazon FSx for Windows File Server

NTFSアクセス権を設定する

ファイルサーバーを実際に運用するにあたって、共有フォルダー内のサブフォルダーやファイルに対してアクセス権限 (いわゆる「NTFSアクセス権」) の設定は必須かと思います。

NTFSアクセス権の設定を行う手順は、一般的なWindowsの手順と変わりません。 すなわち、エクスプローラーで共有フォルダー上の対象フォルダーを開き、フォルダーまたはファイルを右クリックして「プロパティ」を選択してから「セキュリティ」タブを選択して、アクセス権の画面で設定を行うことになります。

これは「管理サーバー」上で行うことも可能ですし、適切な権限を持ったユーザーがクライアント上のエクスプローラーを使って行うことも可能です。

なお、FSx for Windows File Serverにおいて「NTFSアクセス権」の設定を行う場合、通常のWindowsファイルサーバーでの操作では遭遇しない「プチ・ハマりポイント」があります。
詳しくは下記のブログ記事を参照してみてください。

各種オプション機能の設定

ファイルシステムの作成時に設定できない機能については、作成後に設定を行う必要があります。

設定できる機能および設定方法については、この後の「FSx for Windows File Serverの機能」を参照してください。

FSx for Windows File Serverの機能

ここでは、FSx for Windows File Serverで利用できる各種機能について説明します。

DNSエイリアス

FSx for Windows File Serverを導入すると、デフォルトで「amznfsxXXXXXXXX」というようなホスト名が自動付与されます。(「XXXXXXXX」はランダムな英数字)
DNS名は「amznfsxXXXXXXXX.example.com」という感じになり、クライアントからアクセスする際のアドレス表記は「\amznfsxXXXXXXXX.example.com\share\foo.txt」といった感じになります。

ホスト名が「amznfsxXXXXXXXX」という分かり辛い名前だと困る!という場合もありますよね。
そのために、FSx for Windows File Serverには「DNSエイリアス」という機能があります。
これは文字通り、プライマリなホスト名の他に「エイリアス」として分かり易いホスト名 (例えば「fileserver01.example.com」など) を設定できる機能です。

DNSエイリアス機能は、DNSの「CNAMEレコード」を使って別名による名前解決を可能にします。
ただし、DNS CNAMEの設定に加えて、Active DirectoryのKerberos認証のために必要となる「サービスプリンシパル名 (SPN)」の設定も行う必要がある点に注意が必要です。

「DNSエイリアス」機能のより詳しい説明と設定方法については、下記のブログ記事を参照してください。

監査ログ

FSx for Windows File Serverにおける「監査ログ」とは、ファイルサーバーに対するアクセス履歴を記録する機能です。
FSx for Windows File Serverの監査ログは、Windowsイベントログの「セキュリティ」ログに相当します。

監査ログには「誰が (ユーザーID)」「どこから (アクセス元IPアドレス)」「どのファイル/フォルダーに対して」「どのようなアクセス (作成・変更・削除など) を行ったのか」といった詳細な情報が記録されます。

監査ログはAWSの以下のリソースに対して出力することができます。

  • CloudWatch Logs
  • Kinesis Data Firehose

監査ログの出力はデフォルトでは有効になっていないため、FSx for Windows File Serverの導入時に「有効」に設定する必要があります。 (導入後に設定を「有効」または「無効」に変更することも可能です)
また、監査ログの記録を開始するためには、Windows上で監査の対象となるフォルダーやファイルを設定する必要があります。

「監査ログ」機能のより詳しい説明と設定方法については、下記のブログ記事を参照してください。

※ なお、FSx for Windows File Server自体に対するアクセス (AWS APIレベルのアクセス) については、「監査ログ」ではなく「CloudTrail」へ記録されます。(他のAWSリソースと同様)

バックアップ

FSx for Windows File Serverのバックアップを行う方法としては、以下の2通りが用意されています。

  • FSx for Windows File Serverの標準バックアップ機能
  • AWS Backupサービスを使用したバックアップ

「標準バックアップ機能」は、最もシンプルにバックアップを実現する方法です。
バックアップ実行の周期は「毎日 (=1日1回)」に固定されています。
その他に指定可能なパラメーターとしては「バックアップウィンドウの時間帯」「バックアップ保持世代数 (1~90日)」があります。

「AWS Backup」サービスからFSx for Windows File Serverのバックアップを行うこともできます。
AWS Backupを使うと、標準バックアップ機能では実現できなかった以下のような点を実現することができます。

  • バックアップ実行の周期を「毎日」以外に柔軟に設定できる
  • バックアップ保持世代数を「90日」以上に設定できる
  • バックアップを行ったデータを別のリージョンにコピーする (クロスリージョンバックアップコピー)

FSx for Windows File Serverのバックアップに関する詳しい説明と設定方法については、下記のブログ記事を参照してください。

データ重複排除

「データ重複排除」 (「データ重複除去」とも呼ばれる) 機能とは、ストレージ上に保存されている複数のファイルにおいて「重複している」と見なされる部分については重複部分を共通化することで、物理的なストレージ占有量を縮小する仕組みです。
データ重複排除の機能を有効化することにより、FSx for Windows File Serverに設定した「ストレージ容量」(物理的なサイズ) に対して論理的に保存できるデータ容量を増やすことができます。
FSx for Windows File Serverの利用料金は「ストレージ容量」によって決まりますので (※その他に「スループット容量」によっても料金が発生します)、同じデータ容量を保存する場合でも「データ重複排除」を有効にした場合の方がコストを下げることができます。

なお、データ重複排除において「重複している」と判定するのはファイル単位ではなく、ファイルを一定範囲毎に分割した「チャンク」と呼ばれる単位で重複判定を行います。 したがって、全く同一内容のファイルでなくてもデータ重複排除の対象となり得ます。

「データ重複排除」機能のより詳しい説明と設定方法については、下記のブログ記事を参照してください。

ストレージクォータ

「ストレージクォータ」機能とは、ユーザー単位でファイルサーバー上に保存できるデータ容量の上限を設定する機能です。
クォータは「データ使用状況の監視のみ」または「クォータ上限値を超えるデータ保存の禁止」のいずれかのモードを選択できます。
後者を選択した場合、あるユーザーがクォータで設定されている上限値を超えてデータを保存しようとすると、ユーザーに対して「ディスク容量が不十分です」とメッセージを表示して、データの書き込みを拒否します。

「ストレージクォータ」機能のより詳しい説明と設定方法については、下記のAWSドキュメントページを参照してください。

ストレージクォータ - Amazon FSx for Windows File Server

ボリュームシャドウコピー (VSS)

Windowsにおける「ボリュームシャドウコピーサービス」(VSS) とは、ディスクボリュームのスナップショットを生成する機能であり、データの高速バックアップ処理などに利用されています。
FSx for Windows File Serverにおいて「ボリュームシャドウコピーサービス」を有効に設定すると、ファイルサーバー上でファイルの変更や削除を行った際に「変更・削除を行う前のデータ」がスナップショットにより自動的に保存され、一定期間保持されるようになります。
更に、ファイルサーバーを利用するクライアントから「以前のバージョンの復元」の操作が利用できるようになり、変更・削除したデータを任意の時点の状態に戻すことが可能となります。

エンドユーザーがファイルサーバーのデータを誤って変更したり削除した場合に、ファイルサーバーの定期バックアップデータから対象データを復元する方法だと、管理者がバックアップデータから対象データを探したり、エンドユーザーと復元データのやり取りを行ったりする手間が生じます。
しかし、「以前のバージョンの復元」機能であればエンドユーザーが自分で操作してデータ復元を行うことができるため、管理者の運用コスト削減と、エンドユーザーのエクスペリエンス向上を図ることができます。

「ボリュームシャドウコピー」機能のより詳しい説明と設定方法については、下記のブログ記事を参照してください。

アクセスベースの列挙 (ABE)

「アクセスベースの列挙」 (Access-based Enumeration: ABE) とは、ユーザーがエクスプローラーで共有フォルダーを閲覧した時に「共有フォルダー内の全フォルダーではなく、自分がアクセス可能なフォルダーのみを列挙して表示する」機能のことを指します。
「アクセスベースの列挙」機能を使うことによって、以下のような効果を得ることができます。

  • 権限の無いフォルダーを見せないことで、ユーザーに余計な興味を持たせなくする
  • 大量のフォルダーが存在する場合に、必要なフォルダーのみ絞って表示されるため、見易くなる

「アクセスベースの列挙」機能のより詳しい説明と設定方法については、下記のブログ記事を参照してください。

データ保存時の暗号化 (KMS暗号化)

FSx for Windows File Serverにおいて、データ保存時の暗号化は常に有効になっています。(「暗号化しない」というオプションはありません)

データ保存時の暗号化はWindowsの機能ではなく「KMS (Key Management Service)」の機能を利用しています。
KMSによる暗号化・復号は透過的に行われるため、ユーザーやアプリケーションが特に意識する必要はありません。

FSx for Windows File Serverの導入時に「KMSキー」の種類を選択することができます。

  • AMS管理KMSキー (aws/fsx)
  • カスタマー管理KMSキー

デフォルトでは「AMS管理KMSキー」が選択されています。
「カスタマー管理KMSキー」を選択する場合は、KMSにおける「カスタマー管理KMSキー」の利用方法について別途確認してください。

「データ保存時の暗号化」機能のより詳しい説明と設定方法については、下記のAWSドキュメントページを参照してください。

保管時の暗号化 - Amazon FSx for Windows File Server

データ転送時の暗号化 (SMBプロトコルの暗号化機能)

データ転送時の暗号化は、SMBプロトコルの暗号化機能によって実現されています。
SMB暗号化は「SMB 3.0」で追加された機能であり、FSx for Windows File ServerではクライアントのSMBバージョンが「SMB 3.0以降」であれば、自動的にデータ転送が暗号化されます。 一方、クライアントが「SMB 2.1以前」である場合は、データ転送は暗号化されません。

FSx for Windows File Serverの設定により、「データ転送時の暗号化の強制」を設定することができます。
暗号化の強制が設定されている場合、「SMB 3.0以降」のクライアントは問題なくアクセスできますが、「SMB 2.1以前」のクライアントはアクセスを拒否されます。

「データ転送時の暗号化の強制」の設定方法については、下記のブログ記事を参照してください。

DFS名前空間

「DFS名前空間」機能とは、Windowsの「DFS」(分散ファイルシステム) が提供する機能の一つであり、複数のファイルサーバーをグループ化することで、あたかも全体で一つのファイルサーバーであるかのように見せることができます。

DFS名前空間を利用する際には、予め「DFS名前空間サーバー」を導入する必要があります。
EC2 Windowsインスタンスまたはオンプレミス環境のWindows Serverに対して「役割と機能の追加」で「DFS名前空間」役割サービスをインストールすることで「DFS名前空間サーバー」とすることができます。

DFS名前空間サーバー上で、同一のActive Directoryドメインに参加している複数のWindowsファイルサーバー (FSx for Windows File Server、あるいは、オンプレミスのWindows Server) を「DFS名前空間」へ追加することで、ファイルサーバーを「DFS名前空間」の管理下に置きます。

「DFS名前空間」機能のより詳しい説明と設定方法については、下記のAWSドキュメントページを参照してください。

DFS 名前空間を持つ複数のファイルシステムをグループ化する - Amazon FSx for Windows File Server

「AWS DataSync」によるデータ同期

FSx for Windows File Serverの複数のファイルシステムの間、もしくは、「FSx for Windows File Serverファイルシステム」と「オンプレミスのWindowsファイルサーバー」の間でデータの同期や移行を行うために、「AWS DataSync」サービスを利用することができます。

以前は、FSx for Windows File Serverのデータ同期・データ移行を行う方法としては、Windowsの「DFSレプリケーション」機能を利用する方法が案内されていました。
しかし、前述の「シングル構成/冗長構成の選択」で説明した通り、現行のボリュームタイプである「シングルAZ 2」および「マルチAZ」では、DFSレプリケーション機能が使用できなくなっています。 その代わりに「AWS DataSync」サービスを使用したデータ同期・データ移行の方法が案内されています。

「AWS DataSync」を使ったデータ同期・データ移行の方法については、下記のブログ記事を参照してください。

管理方法

最後に、FSx for Windows File Serverを管理する方法について説明します。

FSx for Windows File Serverの管理方法には、大きく以下の4通りの方法が存在します。

  • (1) マネジメントコンソールを使用する
  • (2) Windows管理ツール「共有フォルダー (fsmgmt.msc)」を使用する
  • (3) エクスプローラーを使用してFSx上の共有フォルダーを操作する
  • (4) PowerShellコマンドレット (「Amazon FSx CLI」) を使用する

管理の対象・目的に応じてこれら4つの方法を使い分ける必要があります。

(1) マネジメントコンソールを使用する

マネジメントコンソールから管理対象のFSx for Windows File Server「ファイルシステム」のプロパティを開き、GUI画面から各種設定の変更を行います。

この方法で管理できるのは、以下の内容です。

  • ストレージ容量の変更
  • スループット容量の変更
  • DNSエイリアスの設定変更 (※ 併せて、Active Directoryドメインコントローラー上での設定も必要)
  • 監査ログの設定変更 (※ 併せて、エクスプローラー上で監査対象フォルダー/ファイルの指定が必要)
  • バックアップ (標準バックアップ機能) およびメンテナンスウィンドウの設定変更

(2) Windows管理ツール「共有フォルダー (fsmgmt.msc)」を使用する

「管理サーバー」上でWindowsシステム管理ツール「共有フォルダー」(fsmgmt.msc) を使って、FSx for Windows File Serverへリモート接続を行った上で、各種設定を行います。

この方法で管理できるのは、以下の内容です。

  • 共有フォルダーの作成・削除
  • 共有アクセス権限の設定
  • セッションおよび「開いているファイル」の管理

(3) エクスプローラーを使用してFSx上の共有フォルダーを操作する

エクスプローラーでFSx for Windows File Serverの共有フォルダーへアクセスして、フォルダー/ファイルの「プロパティ」から各種設定を行います。

この方法で管理できるのは、以下の内容です。

  • 共有フォルダー上のサブフォルダーの作成・削除
  • NTFSアクセス権限の設定
  • ファイルアクセス監査項目の設定

(4) PowerShellコマンドレット (「Amazon FSx CLI」) を使用する

「管理サーバー」上でPowerShellコンソールを起動して、FSx for Windows File Serverへリモート接続を行った上で、PowerShellコマンドレットを実行して各種設定を行います。

この方法で管理できるのは、以下の内容です。

  • 「データ重複排除」の設定
  • 「ストレージクォータ」の設定
  • 「ボリュームシャドウコピー」の設定
  • 「アクセスベースの列挙」の設定
  • 「データ転送時の暗号化の強制」の設定

また、「共有フォルダーの作成・削除」など、GUIを使って設定できる一部の設定項目について、PowerShellを使って管理を行うことができるものもあります。

FSx for Windows File Serverの管理のためにAWSが用意した専用のPowerShellコマンドレット群があり、AWSはこれを「Amazon FSx CLI」と呼んでいます。

「Amazon FSx CLI」を利用する方法として、以下のように大きく2通りの方法があります。

  • Enter-PSSessionコマンドレットを使った「リモートPowerShellセッション」による方法
  • Invoke-Commandコマンドレットを使った「リモートでのPowerShellコマンドの都度実行」による方法

多くの管理作業は前者「リモートPowerShellセッション」による方法で行うことができます。
ただし、一部の作業については後者の「リモートでのPowerShellコマンドの都度実行」を使う必要があります。

「Amazon FSx CLI」を使った管理方法、および、上記の2通りの操作方法の違いについては、下記のブログ記事を参照してください。

おわりに

以上、『AWS 再入門ブログリレー 2022』の24日目のエントリ『Amazon FSx for Windows File Server』編でした。

明日 (3/9) はなかはらによる『Amazon Connect』の予定です。お楽しみに!!

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.